
IFF Document Outline v0.1 Beta


What is this format for?

This document contains a proposed IFF Document FORM. This structure is in it's early days and still requires some pampering. While I can easily ensure that this document structure will fill the needs of Soft-Logik products (and I will ensure that future versions of PageStream are compatible) I can not speak for others. While it would be nice to get other information programs to support this format in the future, a more immediate need is to ensure they CAN support this format in the future. Other points of interest would be add on products. For example Grammar Checkers, Indexers, Automated Layout, etc...

What spurred this one? HotLinks! For those of you who are unaware of what HotLinks is, let me explain. It's the exchange of Live Data. It's the ability to do work group editing. It's the ability to edit pieces of a large project in smaller pieces and have them assembled automatically. It's Publish/Subscribe on the Mac. It's DDE/OLE on the IBM. It's neat.

What exactly does it do? It merely is a database of sorts of all project pieces, keeping track of owner, privileges, name, description, version, who is editing the piece, etc. When one program wants to edit a piece, it asks for permission to edit, edits it if it got the write lock and then updates the piece if desired, and then frees the lock. If that piece is in use elsewhere, then that copy will be updated instantly if it's loaded, or updated the next time it's loaded.

What does this have to do with the document structure? Everything! For this to work, then programs must write everything they read, and agree on a format to exchange. If a user writes out a publication, edits in another program, and then goes back to the originating program and it can't read the file or changes that he had made (formatting, colorizing, sound score, whatever) is gone, the whole thing failed and should be thrown in the trash.

This applies to all information passed about. The DOC structure contained below also contains several subFORMs, and these FORMS are generally pieces that can be edited in other programs wanting to deal with those piece types. For example, subFORM ILBM of course can be published from within PageStream, edited in a bitmap editor, and then updated automatically in PageStream. Same for FORM DTXT and text editors, FORM DR2D and drawing programs, and standards not yet proposed such as Graphs, Tables, Crossword puzzles....

The current FORMs that are well on their way are ILBM (of course :-) and DTXT. These are supported by BME and PageLiner respectively, and PageStream supports both. Do to the nature of IFF and the way text commands and tags are implemented in DTXT, these formats can and will be extended to support new data. However, they must be backwards compatible with the following chunks.

The current ILBM chunks that are considered legal and valid are:
BMHD - this has been extended to include picture type (CMYK, RGB, Greyscale,etc) and x&ydpi.
CMAP
BODY
HLID - this is only used when writing a local copy of the data that has also been published via HotLinks. it is valid inside a HotLinks file, but redundant, and possible outdated.
XBMI - this also is only used when writing a local copy of the data for compatibility with naughty ILBM readers. It is redundant considering that this info is now inside the BMHD (where it should be !)

The current DTXT chunks that are considered legal are valid are:
CSET
DTAG
DTXT
HLID - same as above for ILBMs

Now, let's get on with some round one definitions. If you run across something
you have a problem with, post it on BIX, fax me, what ever. I will try and sort everything out so that everyone can support everything. Also, if it's not in this document, others won't know to support it. EVERYTHING must be here, and as accurate as possible.

Deron Kazmaier
Soft-Logik Publishing Corp.

BIX:		dKazmaier
GEnie:		Deron.K
CIS:		76317,3633
Soft-Logik BBS:	1-314-894-0057 Account #1
U.S.Mail:		11131 F South Town Sq., St. Louis MO 63123


IFF Standard's 101: The basics

This document structure tries to adhere to as much of the IFF 85 standard as possible. If you notice something that is wrong or being done by someone else in a different way, let us know. I am not trying to reinvent the wheel, only extend it!

each chunk is defined as follows:
ChunkType		4 byte ID that is unique within a specific FORM
Length		4 byte length of the data inside this block
Data		series of bytes with a pad byte at the end if the length is odd

Forms are a special chunk where the ID is FORM and the first 4 bytes of the data in the FORM is the FORM type.

ChunkType is a four byte ID that is unique within the specific FORM definition.
In other words, in a FORM of TYPE_TEXT, a chunk of ID "CMAP" might be a character
map of some sort, where in a FORM of TYPE_PIC, a chunk by the same ID of
"CMAP" but contain a color table.

If length is odd, an extra byte should be written at the end of the data so
that the next ID would padded out to fall on a word boundary. The length of the chunk should not reflect this pad byte, but all FORMS that encapsulate the chuck should count it in their lengths. Also, in chunks that have punks (smaller yet chunks with a 2 byte ID and a 2 byte Length), they too would not include the pad length in the punk, but would include the pad byte(s) in the chunk.

Inside the data should be a group of closely related items. Also, it
would be very verbose to define point size and attribute changes such as those
as a new chunk when they would take up less data then the 8 byte header.
And to break things like invisible hyphens or kerning amounts into their
own chunks might cause some text to increase dramatically in size.

However, some items, such as possible Rulers or Graphics contained inside of
a text block to indicate their location should probably be broken into
something like TextBlock, RuleBlock, TextBlock. You get the idea.

If your HotLinks Read routines finds something that it doesn't understand,
don't throw the data out. The data should be wrapped up in the same
position it was in the original, and should be saved with the document
to disk, as well as re-output by the HotLinks Write routines.
(Note: this non-standard IFF as defined in the EA IFF 85, but important if the user wishes to get back everything he put in!!!!)


All defined chunks should be extensible. Remember that even if you have fully processed a chunk, you should respect it's chunks size, even if it's larger than you expected. (Page 3 from the EA IFF 85 intro)

One problem through out this is managing relationships between Forms or Chunks or even just data. For example, we are calling tags up by their name, and this is fine because they are created by the user visually. Also, by using a name and looking it up, we can guarantee indexing to the right tags without having to worry about offsets that need fixing up. Reason for this is that if an applications is editing the file that does not support tags and it's related indexing, then and index would get out of sink with the data and would corrupt the data. Now you ask why do I mention this? It's because some indexes need to be done visually or internally, and to ask the user to enter a unique name would be a bit tedious. We need some way of dolling out unique numbers. Problem is if you break a file off and edit it and then bring it back, you have problems with duplicate numbers. Very bad also. Anybody got an elegant solution I'm missing?

Document Structure FORMs

These forms may need to be LISTs. There purpose is often to define the scope of the sub-forms/objects. For example, the PAGE FORM will contain objects that are on that page, and could be in a chapter/section form.

The MasterPage FORM contains Objects, and can be defined in a Document,Section or Chapter Form, and this defines it's scope. The Page Forms defined within it's scope must be able to reference a MasterPage by it's unique name. This allows several master pages to be defined, and used nearly randomly (as long as its scope is valid)
 
Those chunks in braces {} (or italics) below are optional. This mean that they would use the previously defined chunk in the layer above or use a default that is defined for the chunk.



Document Form (DOC )
	{Publish Chunk}
	{Desc Chunk}
	{Section # Style Chunk}
	{Chapter # Style Chunk}
	{Page # Style Chunk}
	{PageDim Chunk}
	{ColumnGuides Chunk}
	{Guides Chunk}
	{Grid Chunk}

	Document Name

The DOC FORM contains all sub forms. (Section,Chapter,MasterPage,Page,Objects)


Section Form (SECT)  scope: Document
	{Publish Chunk}
	{Desc Chunk}
	{Section # Style Chunk}
	{Chapter # Style Chunk}
	{Page # Style Chunk}
	{PageDim Chunk}
	{ColumnGuides Chunk}
	{Guides Chunk}
	{Grid Chunk}

	Section Name
	Section Number
	Flag (AutoNumberSections)
	Flag (OddPageAlignment)
	Chapter Range (begin,#)


Chapter Form (CHAP)  scope: Document,Section
	{Publish Chunk}
	{Desc Chunk}
	{Chapter # Style Chunk}
	{Page # Style Chunk}
	{PageDim Chunk}
	{ColumnGuides Chunk}
	{Guides Chunk}
	{Grid Chunk}

	Chapter Name
	Chapter Number
	Flag (AutoNumberChapters)
	Flag (OddPageAlignment)
	Page Range (begin,#)


MasterPage Form (MPAG)  scope:Document,Section,Chapter
	{Publish Chunk}
	{Desc Chunk}
	{ColumnGuides Chunk}
	{Guides Chunk}
	{Grid Chunk}
	{PageDim Chunk}
	{Page # Style Chunk}

	Type (Left / Right / Single)
	MasterPage Name

Page Form (PAGE)  scope: Document,Section,Chapter
	{Publish Chunk}
	{Desc Chunk}
	{ColumnGuides Chunk}
	{Guides Chunk}
	{Grid Chunk}
	{PageDim Chunk}
	{Page # Style Chunk}

	From MasterPage Name
	Page Number



Document/Page Layout Chunks

PageDim Chunk
	Upper Left Coordinate
	Lower Right Coordinate
	Flag (orientation (Landscape/Portrait))
extend DRHD chunk. Perhaps should call it as such


ColumnGuide Chunk
	Inside Margin
	Outside Margin
	Top Margin
	Bottom Margin
	Horizontal # of Columns
	Horizontal Space Between Columns
	Vertical # of Columns
	Vertical Space Between Columns
this is to define a magnetic guides around the column locations. Perhaps this should just be a list of boxes? At the least, this definition should be repetitive so you can create newspaper format where the top half will have a different layout than the bottom (pure randomness actually)

Grid Chunk
	XOffset
	YOffset
	Grid Width
	Grid Height
	Snap Strength
	Flag (On/Off)
grid snap definition. Perhaps a box range this exists in. ie deferent grids in different locations. what about diagonal grids.(ha ha)

Guide Chunk
	# Horizontal
	X1,X2,X3,X4...,XN
	# Vertical
	Y1,Y2,Y3,Y4...,YN
	Snap Strength
	Flag (On/Off)
guide snap locations. similar to column but for non-columnar layout portions. diagonal?

General Chunks

Publish Chunk
	Hotlink I.D.
	Version #

	ULONG	type,HLID
	ULONG	chunk length

	STRUCT,8	lock, 0=unpublished
	ULONG	version

Description Chunk
	Creation Date
	Modification Date
	Name
	Comment
	Author

	ULONG	type,DESC
	ULONG	chunk length

	ULONG	creation date
	ULONG	mod date
	STRING	name,0
	STRING	comment,0
	STRING	author,0


NAME Chunk
	ULONG	type,NAME
	ULONG	chunk length

	STRING	name,0


ANNO Chunk
	ULONG	type,ANNO
	ULONG	chunk length

	STRING	annotations,0


AUTH Chunk
	ULONG	type,AUTH
	ULONG	chunk length

	STRING	author,0


(C) Chunk
	ULONG	type,(C) 
	ULONG	chunk length

	STRING	copyright text, 0
by the way, (c) is not a legal representation for copyright.




Tag Chunk Definitions

Tag Chunk (scope: Document, Section, Chapter, MasterPage, Page)
Tags can recursivly call previously defined tags.

	ULONG	type,DTAG
	ULONG	chunk length

		UWORD	length
		UBYTE	type
		UBYTE	flag
		STRING	name, 0
		STRING	attribute data


Types are of the groups:
TAG_TEXT		0	;used for text tags
TAG_FILL		1	;used for filling objects
TAG_LINE		2	;used for stroking objects
TAG_COLOR	3	;used for coloring text/fills/lines
TAG_WITHTEXT	4	;for text insertion (chap heads/db merge)
TAG_TEXTMACRO	5	;should be flag for a true insertion?

These are attributes that can be defined for text & objects. To name them just put them in a DTAG and assign the DTAG. This can be for any of these effects.



Display Attributes


Fill Attributes
	Style
		Solid
		Pattern
		Graduated Fill
		Log Fill
		Radial Fill
		Fractal
		Complex
	Color
	Halftone
	PutMode

Line
	Offset (>o = to the right)
	Width
	Style (dash pattern)
	BeginStyle
	EndStyle
	Fill Attributes

LineEnd
	(arrows,rounded, tapered, etc...)
	polygon shape
	need distance to subtract from end of line
	need scale method/factor (width/height min./max.)
	extend DR2D structure?


Color
	Type
		Gray
		RGB
		HLS
		HSV
		CMYK
		CIE
		YCC
		TekColor
		Pantone
	CMYK Equivalent value for display & 4 color sep
	Transparency
	Flag (Spot color)

??Halftone
	(for Yellow,Magenta,Cyan,Black,Custom)
	SpotFunction
		TrueSpot
		Round
		Elliptical
		Square
		Cross
		Line
		Custom
	Frequency
	Angle
	DotGain Function

Trapping
	Spreads/Chokes
	Auto/Manual
	Amount (.0001 increments) .003-.006 good defaults
	Trap Type
		No Trap
		No Knockout (specific)
		Trap with common
		Trap with uncommon
		Trap with Black (with color?)

Need provisions for:
	gamma correction / UCR / GCR
	max. ink coverage (300% usually 250-260% for web presses)

Object Types
These are some of the forms one can expect to find on a page. These forms may have chunks that could be defined outside the scope of the form. For example, tags for a documents DTXT could be stored in the first nest level of the DOC structure. This would then be used by all subsequent DTXT forms. Same for others. Also, all drawn object on a page do not need to belong to a drawing. For example a simple rule drawn across or down a page. This would belong to the page form as part of it's description? Also, each of these forms can stand by its self as a file. For example, a DTXT form is used by PageLiner for it's native file format as well as the means of exchange text with PageStream. The DTXT would contain copies of all chunks whose scope is valid within the DTXT and are/could be used by the DTXT.

Text Form
This is DTXT. The chunks CSET, DTAG, & DTXT are currently defined and valid.

Bitmap Form
This is ILBM. The chunks BMHD, CMAP, & BODY are currently defined and valid.

Drawing Form
This is DR2D. We need a LOT of extensions to build this into something that can represent a drawing even created in PageStream, much less one done in ArtExpression. Needed extensions include box/circle/arc objects, pattern fill, CMYK & named colors, etc... DTAG chunks are also includable to allow named fills/etc.

Music Form
Since I know so little about this, I will leave this alone.

Sound Form
Hey, why not 8SVX? :-)

Animations Form
Hey, why not ANIM? :-)

Equations Form
This is a must if we are to get products like TeX to write out in this format. Should contain the actual formula, as well as the information needed to regenerate the formula.  (as a CAT with DR2D to provide display info?)

Table Form
For spreadsheets and other forms of columnar data. Should be full form enough that spreadsheets can save in this format as their native format.

Graph Form
For spreadsheets and other forms of columnar data. Should contain the actual graph , as well as the information needed to regenerate the graph.  (as a CAT with DR2D to provide display info?)

EPS Form
Encapsulated PostScript. Not very useful, but it's a must for DTP applications that support non-Amiga drawing programs. It would be nice if ANY eps drawing/effect could be converted in an IFF structure. That to me would indicate success in the drawing field.

	Scale
	Bitmap Chunk
	ComplexPolygon Chunk
	EPS Data Chunk


Notes: In review of the above, it seems imperative that we have a standard that allows for generic drawing/descriptions to be attached to complex data that will allow any program to provide basic display/manipulation (sizing/moving/etc...) while still keeping the original body of info. For data of a complex nature, this display info should be better then a generic bitmap. If someone does a graph in a spreadsheet, and print it out from another program to a lino, they probably want something better than a bitmap. Same if it's a presentations package displaying on a 24-bit device. The user would be unhappy with a B/W or 8 color dithered picture.

Note:
Most of the forms that follow will need addition info if they are inside of another drawing/document. For example, the text alone is enough for some word processors, but a complex WP/DTP program will need to know where it is on which pages, etc. Which brings up an interesting problem. Text can exist on several pages in PageStream, but would generally be place on a single page like any other form. Perhaps DTXT should exist outside of the pages scope if it spans more than one page.



IFF DTXT Form

Columns Chunk  scope: Masterpage,Page
	Publish Chunk
	AnchorTo Chunk
	TextFlow Chunk (standoff / posted flow polygon)
	Bounding Box
	Rotation
	Line Chunk
	Fill Chunk
	Flag (floating right edge)
	Article Chunk
Article Chunk
	Text Chunk
	List of Object Chunks to flow in
Outlines Chunk
Index Chunk
TableOfContents Chunk



CSET Chunk

This chunk is to define the character set used in text. Any 1 byte character set you choose will not have certain special characters in it. This is guaranteed due to the fact that their are more than 256 unique glyphs used through out the world. To overcome this, we have created a sort of mapping table that will take an arbitrary character number, and map it to a fixed number. This fixed number is the Unicode character set right now. As luck would have it we needed this for PageStream right away as the Amiga character set does not support many of the typographical characters that PageStream does like  ,   , em  and en ­ dash, bullets, etc. So, if you intend on reading PageLiners native DTXT files, or HotLinking text with PageStream, better support this!

Note: This table is to help a program determine how to display and edit the text. A program reading this data should NOT throw out character it doesn't understand or can't display. Either make a good guess as to what to use (for example, if you lookup a character in the table and determine that it is an open quote, display it as inch marks) or display a character reserved for unknown characters. (for example, PageLiner uses the box character)

Note: You do not need to scan this table every time the user enters a character or you display a character. We build a 256 byte array to go from internal to Amiga, and another 256 byte array to go from Amiga keyboard entries to internal. You may also want them to be able to enter standard Unicode numbers, and then search the table for the appropriate character.

The CSET chunk is comprised of several Punks or small chunks. These punks are like a chunk but they use 2 bytes for the ID, and 2 bytes for the length, as opposed to chunks which use 4 bytes for both.

NM Punk
  character set name (null terminated C string)
	string\0

To reference defaults for Amiga / IBM  / Mac / ST / Adobe Standard Encoding how about character set names of
Amiga	Latin1
IBM	IBM
Mac	Mac
Adobe	Adobe

Example:
NM,0x0007,Latin1,0x00, followed by a pad byte 0x00

UC Punk
Internal character set to Unicode mapping table.

  source / destination size
  number of entries
  array of source character to destination Unicode

 UBYTE	CharSize;
 UBYTE	UnicodeSize;
 UWORD	NumberEntries;

where (source/destination) type is
	0- vnum
	1- 1 byte
	2- 2 byte
	3- 3 byte
	4- 4 byte (hey, it sounds crazy, but ANSI / ISO was talking about it)

A character set which uses only 1 byte to depict it's glyphs will have a CharSize of 1. Anyone using the current Unicode standard will be using a CharSize of 2 (or possible vnum, which will save you a few bytes in size, but this is unsupported in the current release of PageStream/PageLiner)

Example:
UC,0x0000+4+252*3
   0x01,0x02,0x00fc
     0x01,0x2625
     0x20,0x0020
               ....
     0x7e,0x007e
     0x7f,0x00a0
     0x80,0x221a
               ....

	LI Punk
Because Unicode does not support Ligatures (they are typographical glyphs, not language glyphs is their reasoning) we needed a way to depict ligatures that are representing in a character set. (such as fi or fl ligatures)

  source / destination size
  number of entries
  array of struct {
	character number
	number of Unicode entries
	array of Unicode entries
}

 UBYTE	CharSize;
 UBYTE	UnicodeSize;
 UWORD	NumberEntries;

 CharSize	Character number
 UBYTE	number of Unicode entries
 UnicodeSize*number of Unicode entries	Unicode entries

where (source/destination) type is same as for UC Punk.

Example:

 LI,0x0016
    0x01,0x02,0x0003
      0xb0,0x02,0x0066,0x0069
      0xb1,0x02,0x0066,0x006c
      0xb2,0x02,0x0050,0x0074






You need the current Unicode specs! Get it! We realize it's still changing, but not where it counts. The details are:

The Unicode Standard: Worldwide Character Encoding, Version 1.0, Volume 1
by The Unicode Consortium
published by Addison-Wesley
ISBN 0-201-56788-1
$32.95 US
$42.94 Cnd


Font Chunk
	Full Name String
	Family Name String
	Attributes String
	Desc (Serif, SanSerif, Block, etc?)
	Type  (Adobe Type 1, CompuGraphic Intellifont, BitStream Speedo, etc..)
	character map (important!)
	kerning pair table
	composition table
This chunk would normally be to indicate which fonts the document uses, and any pertinate info for the document. Most programs would need to interpret the font anyway, and could derive most of this info that way.

Full Name is the complete name of the font. This would be the FontName in Adobe Type 1 fonts. (ex, Helvetica-Bold)
Family Name is the same for all fonts in the same family (ex, Helvetica)
Attributes is the styles specific to this font (ex, Bold)
characterset map would be mapping from internal numbers to Unicode. similar to Character Map chunk. from internal to Unicode
Kerning pair table 


DTXT Chunk

This chunk is the actual text data filled in with characters and commands. Basically, if you grab a byte in the data stream, and it's not a 0, then you can display it, assuming you take into account the CSET. If it is a zero, then to just skip the command, you read the next 3 vnums and then skip the last vnums worth of bytes. If you don't even care about the command or it's flags, you can skip those vnums without actually processing them. Just skip until you come to a character <0x80 (high bit is not set) and you have that last character in the vnum.


Text/Tag Attributes

Attribute Commands follow the format:
(BYTE) 0, (VNum) Command, (VNum) Flags, (VNum) Length, (Length) Data

where VNum is a number encoded as,
	value=0
	while (*byte>127)
		value<<7
		value+= *byte++ - 128 ;
	value+=*byte++

SVNum is like VNum, only that bit 6 of the first byte indicates whether or not the number is negative. If this bit is set, then negate the number after processing it. Bit 7 always indicates whether or not to get another byte just like another VNum.

flags are
xxx00 - no displayable data
xxx01 - non-editable displayable data
xxx10 - editable displayable data

x00xx - keep last occurance of command
x01xx - delete it
x10xx - leave it

0xxxx - not white space
1xxxx - white space (possible word break)

TEXT_TAB		1	;tab (data is position?)
TEXT_NEWLINE	2
TEXT_EOC		3	;forced end of column
TEXT_EOP		4	;forced end of page
TEXT_BCCB		5	;begin conditional column break
TEXT_ECCB		6	;end conditional column break
TEXT_BCPB		7	;begin conditional page break
TEXT_ECPB		8	;end conditional page break

TEXT_PARANUM	9	;paragraph number command (auto inc?)
TEXT_PAGENUM	10	;page number command (text of #,format)
TEXT_CHAPNUM	12	;chapter number command (text of #,format)
TEXT_SECTNUM	13	;section number command (text of #,format)

TEXT_MARK		14	;mark point
TEXT_BRANGE	15	;begin range point
TEXT_ERANGE	16	;end range point
TEXT_FOOTNOTE	17	;footnote. (data includes #, location,(&text?))
TEXT_RULER	18	;ruler. (data is tab stop locations & type)
				(vnum)type,(vnum),offset
TEXT_AKERN	19	;auto kern (data is table#?) 
TEXT_AHYPHEN	20	;auto hyphen (data is languagetable#?)
TEXT_TRACKRANGE	21	;tracking range (10000em, Min,Max,Opt)

TEXT_DROPCAP	22	;drop cap. (mode,lines tall)
Date (flag, DATA)
Time (flag, DATA)

TEXT_CSET		23	;set character set (name)
TEXT_MULTIBYTE	24	;multibyte mode (0=vnum,1=1byte,2=2 byte...)

TEXT_TAG		30	;tag. (tag name)
TEXT_FONT		31	;font (font name)
TEXT_ATTRB	32	;attribute (chars identifing attribute)
TEXT_POINT	33	;point size (point,{ypoint})
TEXT_JUSTIFY	34	;justification ( mode)
TEXT_PARAGRAPH	35	;paragraph format (VNUM) 1/10000pt
TEXT_INDENT	36	;left/right indent (VNUM) Left,(VNUM) right)
TEXT_LEADING	37	;leading (VNUM) flag-auto/fixed, (VNUM) value)
TEXT_PARALEAD	38	;paragraph leading (VNUM) flag- auto/fixed, (SVNUM) value
TEXT_TRACKING	39	;intercharacter tracking (SVNUM) 1/10000em
TEXT_BASELINE	40	;super/subscript (SVNUM) offset,(SVNUM) % size

TEXT_MKERN	50	;manual kern. (SVNUM) 1/10000em
TEXT_AKERN	51	;auto inserted kern. (SVNUM) 1/10000em
TEXT_MHYPHEN	52	;manual soft hyphen. {(VNUM) priority value}
TEXT_AHYPHEN	53	;auto soft inserted kern. { (VNUM) priority value}


ATTRB_NORMAL	"N"
ATTRB_BOLD	"B"
ATTRB_LIGHT	"L"
ATTRB_ITALIC	"I"
ATTRB_SHADOW	"S"
ATTRB_OUTLINE	"O"
ATTRB_UNDERLINE	"U"
ATTRB_WEIGHT	"w"	;following byte is weight value
ATTRB_SPECIAL	\	;string of style ending with \

JUSTIFY_LEFT	0
JUSTIFY_CENTER	1
JUSTIFY_RIGHT	2
JUSTIFY_CHAR	3
JUSTIFY_WORD	4
JUSTIFY_AUTO	5


Some things left to sort out and define:
	Tab Ruler
		Left,Center,Right,Decimal
		Leader
	Footnote
	Continued From/On
	Line Attributes
	Fill Attributes
	directions (up/down/left/right)

	multibyte systems


IFF ILBM Form

Some generic chunks that could be part of it.

Publish Chunk
AnchorTo Chunk
TextFlow Chunk (standoff / posted flow polygon)
Bounding Box
Rotation
Line Chunk
Fill Chunk

Scale
Translation
Flag (mechanical)
Clip Chunk
Halftone
Transformation Function (contrast/inversion/tonal boost...)

This stuff is part of the standard bitmap header.
X/Y Dpi
Width in Pixels
Width in Bytes
Height in Pixels
Bitplanes
Compression
Type (RGB PALETTE, B/W, RGB, RGBW, CMY, CMYK)
Palette
Bitmap


Bitmap Header (BMHD) Chunk
	ULONG	type, BMHD
	ULONG	chunk length

	UWORD	w,h
	 WORD	x,y
	UBYTE	nPlanes
	UBYTE	masking
	UBYTE	compression
	UBYTE	picType
	UWORD	transparentColor
	 UBYTE	xAspect,yAspect
	 WORD	pageWidth,pageHeight
	UWORD	xdpi,ydpi


where picType is:
0 = ILBM_PALETTE - this makes for backward compatability since this byte was supposed to have been written as a zero anyway. This type will also have a CMAP in the file.
1 = ILBM_GREY - This is used for grey scale images. No CMAP is needed in the file. Number of shades will be 2^nPlanes.
2 = ILBM_RGB - This is used for rgb images, that is images that have no CMAP and are defined as triplets as rgb in the data.
3 = ILBM_RGBA - This is used for rgb images that also have some alpha data included int the BODY. No CMAP is needed.
4 = ILBM_CMYK - This is used for cmyk images. No CMAP is needed.
5 = ILBM_CMYKA - This is used for cmyk images that also have some alpha data included in the BODY.

CMAP
	ULONG	type, CMAP
	ULONG	chunk length

CLUT
	ULONG	type, CLUT
	ULONG	chunk length

BODY
	ULONG	type, BODY
	ULONG	chunk length




IFF DR2D FORM


Group List  scope: Masterpage, Page
	Publish Chunk
	AnchorTo Chunk
	TextFlow Chunk (standoff / posted flow polygon)
	Bounding Box
	Rotation
	Scale

	Flag (Drawing?)

Lines Chunk  scope: Masterpage,Page
	Line Chunk
	Flag (maintain horizontal/vertical)
	Begin X,Y / End X,Y

Boxes Chunk  scope: Masterpage,Page
	Line Chunk
	Fill Chunk

	Flag (Maintain Box)
	Upper Left / Lower Right
	Rounded Corner X / Y Radius

Circles Chunk  scope: Masterpage,Page
	Line Chunk
	Fill Chunk

	Flag (Maintain Circle / Pie lines)
	Center X,Y
	Radius X,Y
	Beginning / Ending Angle


Polygons Chunk (Masterpage,Page)
	Publish Chunk
	AnchorTo Chunk
	TextFlow Chunk (standoff / posted flow polygon)
	Bounding Box
	Rotation
	Line Chunk
	Fill Chunk

	Original Width / Height
	Current X/Y scale (relative to actual size)
	Current X/Y offset
	Clip Polygon (usually fullsize box)
	Article Chunk

	# of Commands
	Commands
		Newpath
		Moveto (x,y)
		Lineto (x,y)
		Curveto (cx1,cy1,cx2,cy2,x,y)
		ArcTo (cx,cy,ba,ea,rx,ry)
		ArcNTo (cx,cy,ba,ea,rx,ry)
		Closepath
		Fillpath
		Strokepath
		cubic
		b-spline


Drawing Form  (Masterpage,Page)
Should be DR2D, or some such

	Publish Chunk
	AnchorTo Chunk
	TextFlow Chunk (standoff / posted flow polygon)
	Bounding Box
	Rotation
	Line Chunk
	Fill Chunk

	Original Width / Height
	Current X/Y scale (relative to actual size)
	Current X/Y offset
	Clip Polygon (usually fullsize box)
	# of Commands
	Commands
		SetLine (Line Chunk/Style)
		SetFill (Fill Chunk/Style)
		SetRotation (Twist/Slant/cx/cy)
		Box (ulx,uly,lrx,lry)
		RBox (ulx,uly,lrx,lry,rx,ry)
		Line (x1,y1,x2,y2)
		Circle (cx,cy,r)
		Ellipse (cx,cy,rx,ry)
		Arc (cx,cy,r,ba,ea)
		EllipticalArc (cx,cy,rx,ry,ba,ea)
		Polygon
			Newpath
			Moveto (x,y)
			Lineto (x,y)
			Curveto (cx1,cy1,cx2,cy2,x,y)
			ArcTo (cx,cy,ba,ea,rx,ry)
			ArcNTo (cx,cy,ba,ea,rx,ry)
			Closepath
			Fillpath
			Strokepath



Definitions
Coordinate
	2 Long Words, x DPI?
	2 Long, Fixed point, measure
	2 Long, IEEE (egads, yuk, barf, but then again it is in DR2D)

NumberStyle (for section, chapter, page numbers)
	Style
		Arabic
		Roman
		One,Two,Three.... (language dependent)
		A,B,C,D,...,AA,AB,AC...
		what about user definable? foreign?
	Case
		UPPER
		lower
		Capitilized

Measure
	Inches
	Centimeters
	Millimeters
	Points
	Picas
	Decipoints
	Millipoints

Language
	American
	English
	French
	German
	Spanish
	Italian
	Swiss-German
	Swiss-French
	...
